IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (UEs) or between UEs and application servers (ASs). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
Within an IMS network, Call/Session Control Functions (CSCFs) operate as SIP entities within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
IMS service functionality is implemented using application servers (ASs). For any given UE, one or more ASs may be associated with that terminal. ASs communicate with an S-CSCF via the IMS Service Control (ISC) interface and are linked into a SIP messaging route as required (e.g. as a result of the triggering of iFCs downloaded into the S-CSCF for a given UE).
A user registers in the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address giving the location at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user using subscription information stored in a Home Subscriber Server (HSS), and allocates an S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs are not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling, and charging for, user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions that would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF, if an S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the HSS, and selects an appropriate S-CSCF based on the received capabilities. It is noted that S-CSCF allocation is also carried for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF. When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Every IMS user possesses one or more Private User Identities. A Private User Identity is assigned by the home network operator and is used by the IMS, for example for registration, authorization, administration, and accounting purposes. This identity takes the form of a Network Access Identifier (NAI) as defined in IETF RFC 2486. It is possible for a representation of the International Mobile Subscriber Identity (IMSI) to be contained within the NAI for the private identity. 3GPP TS 23.228 specifies the following properties of the Private User Identity:                The Private User Identity is not used for routing of SIP messages.        The Private User Identity is contained in all Registration requests, (including Re-registration and De-registration requests) passed from the UE to the home network.        An IP multimedia Services Identity Module (ISIM) application securely stores one Private User Identity. It is not possible for the UE to modify the Private User Identity information stored on the ISIM application.        The Private User Identity is a unique global identity defined by the Home Network Operator, which may be used within the home network to identify the user's subscription (e.g. IM service capability) from a network perspective. The Private User Identity identifies the subscription, not the user.        The Private User Identity is permanently allocated to a user's subscription (it is not a dynamic identity), and is valid for the duration of the user's subscription with the home network.        The Private User Identity is used to identify the user's information (for example authentication information) stored within the HSS (for use for example during Registration).        The Private User Identity may be present in charging records based on operator policies.        The Private User Identity is authenticated only during registration of the user, (including re-registration and de-registration).        The S-CSCF needs to obtain and store the Private User Identity upon registration and unregistered termination.        
In addition to a Private User Identity, every IMS user has one or more IMS Public User Identities (PUIs). The PUIs are used by any user to request communications to other users. A user might for example include a PUI (but not a Private User Identity) on a business card. 3GPP TS 23.228 specifies the following properties of the PUI:                Both telecom numbering and Internet naming schemes can be used to address users depending on the PUIs that the users have.        The PUI(s) take the form of a SIP URI (as defined in RFC 3261 and RFC 2396 or the “tel:”-URI format defined in RFC 3966.        An ISIM application securely stores at least one PUI (it shall not be possible for the UE to modify the PUI), but it is not required that all additional PUIs be stored on the ISIM application.        A PUI is registered either explicitly or implicitly before the identity can be used to originate IMS sessions and IMS session unrelated procedures.        A PUI is registered either explicitly or implicitly before terminating IMS sessions and terminating IMS session unrelated procedures can be delivered to the UE of the user that the PUI belongs to.        It is possible to register globally (i.e. through one single UE request) a user that has more than one PUI via a mechanism within the IMS (e.g. by using an Implicit Registration Set). This does not preclude the user from registering individually some of his/her PUIs if needed.        PUIs are not authenticated by the network during registration.        PUIs may be used to identify the users information within the HSS (for example during mobile terminated session set-up).        PUIs may be used by ASs within the IMS to identify service configuration data to be applied to a user.        
FIG. 1 illustrates schematically example relationships between a user (IMS) subscription and the Public and Private User Identities. In the example shown, a subscriber has two Private User Identities, with both being associated with two Public User Identities (one of the Public User Identities, Public User Identities-2, being associated with both Private User Identities). A Service Profile is associated with each Public User Identity, this profile specifying service data for the associated Public User Identities. A Service Profile is created or modified when an application server is provisioned for a user at the Home Subscriber Server. Each Service Profile comprises one or more initial Filter Criteria (iFCs), which are used to trigger the provision, or restriction, of IMS services. The differences between services offered by Service Profile-1 and Service Profile-2 are operator specific, but may involve different application servers (ASs), and even different charging/rating schemes.
In the example shown in FIG. 1, Public User Identity-1 is associated with a Service Profile-1, whilst Public User Identity-2 and Public User Identity-3 are associated with Service Profile-2. In a typical scenario, the Public User Identity-1 might be an identity that the user gives to friends and family, e.g. “Big_Joe@priv.operator.com”, whilst Public User Identity-2 and Public User Identity-3 might be identities that the user gives to business contacts, e.g. “+46111222333@operator.com” and “joe.black@operator.com”.
3GPP defines a so-called “Implicit Registration Set” concept to identify a set of PUIs that work as a group, and which are registered and deregistered together when any one of the PUIs of the set is registered or deregistered. 3GPP requires that the HSS sends the Implicit Registration Set to the S-CSCF upon registration of a user or upon terminating a call. It has been understood that, at registration, the HSS identifies all PUIs within the Implicit Registration Set, and then identifies all of the Service Profiles associated with these PUIs. The Service Profiles (or selected data from the Service Profiles) containing the PUIs with which they are associated are then sent to the S-CSCF. As a result of this operation, the S-CSCF knows all of the PUIs that belong to the same Implicit Registration Set, as well as their Service Profiles.
A possible use case of the IMS involves a collection of users having a group level subscription to the IMS, but where the individual users themselves have no subscription and of which the IMS is unaware. It is desirable to allow direct inward and outward dialing to the users. This might arise, for example, in the case of a company having a subscription to the IMS and having individual employee stations or terminals attached to an IP private branch exchange (IP-PBX). The employee terminals may or may not be provided with SIP clients. In the latter case, the IP-PBX performs a translation between SIP and non-SIP signalling. Whilst it might of course be possible for the IMS to record an individual PUI for each terminal (within the same Implicit Registration Set), this becomes inefficient as the group size becomes large. ETSI TISPAN defines such a corporate network as a Next Generation Corporate Network (NGCN).
It is possible to include within the Implicit Registration Set associated with a subscription, a wildcarded Public User Identity. “Wildcarded” or “wildcard” is understood here to mean a Public User Identity that contains a symbol or symbol that stands for one or more unspecified characters. The wildcarded Public User Identity has a service profile associated with it. Any node within the IP Multimedia Subsystem which performs checks or processing based upon the Implicit Registration Set, acts upon a received Public User Identity matching a wildcarded Public User Identity in the same way as if the received Public User Identity matched any standard Public User Identity within the Implicit Registration Set. Rather than representing a range of Public User Identities using a wildcarded Public User Identity, such a range may instead be represented by a sub-domain. For example, a range of Tel URIs may be represented by a dialing prefix, whilst a range of SIP URIs may be represented by a corporate domain. This allows routing to and from corporate network users when the corporate network is connected to an IMS network over the Gm reference point.
However, there is a requirement in the TISPAN published specification for Business Communication Requirements (ETSI TS 181 019 (V2.0.0): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Business Communication Requirements)] that expresses that the operator's trust domain should be able to be extended into the corporate network domain where a business trunk between an IMS network and a trusted corporate network is in place. An implication of this is that the P-CSCF in the IMS network must accept a P-Asserted-Identity header sent from the corporate network over the Gm reference point. The P-Asserted-Identity header is a header in a SIP message that contains a SIP URI and an optional display-name. The P-Asserted-Identity is an identity that is used among trusted SIP entities, typically intermediaries, to carry the identity of the user sending a SIP message as it was verified by authentication. The P-Asserted-Identity is inserted into the header field of a SIP message by a SIP entity once the node has authenticated the originating user in some way. A consequence of this is that the P-Asserted-Identity may not represent the originating served user of the IMS network, as the P-Asserted-Identity contains an identity that is authenticated by the remote/corporate/private network.
The S-CSCF normally uses the P-Asserted-Identity to check whether any relevant restrictions have been placed on the originating UE, e.g. is the UE barred from using the requested service. The S-CSCF also uses the P-Asserted-Identity and call case to determine the Initial Filter Criteria (IFCs) for the UE. Assuming, for example, that the IFCs require that the S-CSCF forward the INVITE to a particular AS, the S-CSCF includes at the topmost level of the SIP route header the URI of the AS. It also includes in the subsequent level its own URI, together with an Original Dialog Identifier (ODI). The ODI is generated by the S-CSCF and uniquely identifies the call to the S-CSCF. The AS will itself perform authentication based upon the P-Asserted-Identity contained in the message. It can be concluded from this that the P-Asserted-Identity is used in an originating IMS network to determine the served user, for the network to be able to execute the right policies/services for this user.
As described above, when the trust domain is extended from a public IMS network into another network connected over a Gm reference point, the P-Asserted-Identity can contain a user identity not known in the IMS network. However, a problem arises because the P-Asserted-Identity is also used by originating IMS core systems to determine the served user. When forwarding a message containing a P-Asserted-Identity of a user that does not represent the user currently served by a P-CSCF, and in some cases a P-Asserted-Identity that is not the identity of a known IMS user, the current procedures would either fail, procedures would be executed for the wrong user, or the P-CSCF would drop the P-Asserted-Identity belonging to a different user.